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Executive  Summary 

The  DOD  Computer-aided  Acquisition  and  Logistic  Support  (CALS)  Test 
Network  (CTN)  is  conducting  tests  of  the  military  standard  for  the  Automated 
Interchange  of  Technical  Information  (MrL-STD-1840A)  and  its  companion 
suite  of  military  specifications.  The  CTN  is  a  DoD-sponsored  confederation 
of  voluntary  participants  from  industry  and  government,  managed  jointly  by  a 
technical  staff  at  Air  Force  Logistics  Command  (AFLC)  and  Lawrence  Liver¬ 
more  National  Laboratory  (LLNL).  The  objective  of  CTN  tests  is  to  demon¬ 
strate  and  evaluate  the  interchange  and  functional  use  of  digital  technical 
information  between  industry  and  government  using  the  CALS  standards. 

Publishing  Systems  Structured  Test  No.  1  was  devised  by  the  CALS  Test 
Network  staff  and  several  representatives  of  SGML-oriented  publishing 
vendors  at  TechDoc  XIII  in  August,  1988.  The  objective  of  the  test  was  to 
help  settle  some  of  the  issues  that  arose  during  the  attempt  to  formulate  an 
Output  Specification  to  accompany  the  conforming  Document  Type  Defini¬ 
tion  of  Specification  MIL-M-38784B  (“MIL-B”).  The  approach  was  to  obtain 
consensus  on  interpretation  of  MIL-B  by  having  several  vendors  compose  the 
same  Standard  Generalized  Markup  Language  (SGML)  text  file,  and  then 
comparing  the  results.  The  consensus  might  then  speed  the  process  of  devel¬ 
oping  the  Output  Specification  (OS). 

Two  text  files  (documents)  were  included  on  the  magnetic  tape  sent  to  nine 
volunteering  companies.  The  first  text  file  was  prepared  by  SoftQuad,  Inc. 
and  the  other  by  the  CTN  Technical  Publications  Testbed.  The  SGML  text 
files  were  composed  and  printed  on  paper,  and  returned  to  the  testbed.  The 
resulting  images  were  compared  and  significant  differences  were  photostated 
and  mounted  on  presentation  slides  for  TechDoc  Winter  ’89.  The  last  section 
of  the  report  contains  all  of  the  charts  presented  at  the  TechDoc  Winter  Meet¬ 
ing.  The  charts  are  referred  to  in  the  report  as  Exhibits. 

The  observations  gathered  showed  that  there  was  little  consensus  even  on 
what  might  be  called  major  elements  of  formatting  in  accordance  with  MIL-B 
(see  Figure  1).  In  summary,  the  major  points  of  non-consensus  or  non-com¬ 
pliance  with  MIL-B  are: 

•  Inconsistencies  were  similar  for  both  documents,  but  the  second 
document  tended  to  exaggerate  some  of  them. 

•  Use  of  running  heads  was  not  consistent  with  MIL-B. 
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•  Typography  was  inconsistent  among  vendors  and  with  MIL-B. 

•  Some  vendors  ignored  certain  SGML  tags  that  had  a  major  effect 
on  the  appearance  of  the  composed  image. 

•  The  interpretation  of  attribute  values  in  the  SGML  tags  was  inconstent. 

•  The  process  used  to  create  the  SGML  text  file  for  the  first  document 
did  not  apply  the  DTD  of  MIL-M-28001  correctly.  Also,  the  occur 
rence  of  a  space  character  following  a  hyphen  was  noted  in  several 
cases. 

•  There  was  no  consensus  on  hyphenation  and  justification. 

•  Formatting  lists  and  tables  proved  to  be  less  of  problem  than  was 
expected,  but  the  formats  still  varied  greatly.  (See  Figure  1  and 
Exhibit  5.) 

•  Efficiency  of  page  layout  also  varied  greatly.  The  number  of  pages 
required  to  image  the  first  document  ranged  from  five  and  a  fraction 
pages  to  over  eleven  pages. 

It  is  clear  that  there  is  little  consensus  in  interpreting  MIL-B.  There  seemed  to 
be  some  uncertainty  also  with  respect  to  interpreting  SGML  tags  and  their 
attributes.  It  is  highly  probable  that  any  source  of  format  specification,  be  it 
an  OS  or  another  revision  of  MIL- M-3 8784,  will  have  to  attain  a  degree  of 
rigor  equal  to  the  DTD  that  it  supports. 

The  general  recommendations  of  the  report  are: 

•  Permissible  values  for  attributes  in  Specification  MIL-M-28001 
need  to  more  rigorously  defined. 

•  Acceptance  quality  control  tools  are  needed  to  detect  misuse  of  a 
DTD. 

•  The  OS  now  under  development  could  replace  the  formatting  information 
found  in  MIL-B  and  other  format-oriented  Military  Specifications. 
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•  Future  PSST  tests  might  best  serve  CALS  goals  by  emphasizing  early 
testing  of  changes  and  additions  to  the  CALS  core  standards.  The  impend 
ing  OS  for  Specification  MIL-M-28001  is  one  obvious  opportunity. 

Comments  on  the  initial  draft  of  the  report  were  kindly  provided  to  the  CTN 
Technical  Publications  Testbed  by  Context,  Datalogics,  and  SoftQuad. 
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1  Preparation  and  Processing 

During  the  Graphics  Communications  Association  (GCA)  TechDoc  XIII 
Conference,  August  1988,  discussion  and  debate  carried  over  from  other 
CALS  meetings  about  the  ongoing  effort  to  formulate  an  Output  Specification 
(OS).  An  OS  defines  the  format  of  documents  that  have  been  tagged  in 
accordance  with  the  SGML  Document  Type  Definition  (DTD)  provided  in 
Specification  MIL-M-28001.  The  DTD  is  now  and  the  OS  will  be  an  appendix 
to  the  basic  specification,  MIL-M-28001. 

The  DTD  defines  the  structure  and  content  of  a  conforming  document,  and  the 
OS  will  specify  the  format  or  appearance  of  the  document  in  paper  form.  The 
first  attempt  at  constructing  an  OS  was  unsatisfactory  to  many,  and  therefore 
the  exchange  of  opinions  continued.  Yuri  Rubinsky,  President  of  SoftQuad, 
suggested  that  it  might  be  instructive  to  have  the  same  SGML  text  file  com¬ 
posed  by  several  publishing  systems  vendors  to  see  how  they  interpreted  the 
requirements  of  MIL-M-38784B  (hereafter  known  as  MIL-B).  The  under¬ 
standing  arrived  at  during  the  meeting  at  TechDoc  was  that  each  participant 
would  compose  the  documents  in  the  way  that  best  conformed  to  MIL-B,  in 
their  opinion.  It  was  hoped  that  some  consensus  could  be  derived  from  the 
resulting  images,  and  that  this  consensus  would  contribute  to  forming  a  usable 
OS  for  MIL-B  documents. 

SoftQuad  volunteered  to  prepare  the  SGML  text  file.  The  test  data  thus 
prepared  was  one  chapter  from  a  U.  S.  Navy  technical  manual.  The  file  was 
sent  to  SYSCON  in  MIL-STD-1840A  format,  where  another  text  file  was 
added.  This  second  text  file  had  not  been  passed  through  an  SGML  parser 
and  contained  both  intentional  and  unintentional  tagging  errors.  No  illustra¬ 
tions  were  included  in  either  file  set.  Identical  copies  of  the  two  SGML  text 
files,  tagged  in  accordance  with  the  MIL-M-28001  conforming  DTD,  were 
sent  (in  MIL-STD-1840A  fomiat)  to  nine  vendors  of  publishing  systems  or 
other  interested  parties  that  had  agreed  to  participate  in  the  experiment.  No 
written  instructions  were  sent  with  the  data. 

In  the  first  file  set  (document),  the  U.  S.  Navy  technical  manual  fragment,  the 
origin  and  preparation  of  the  document  was  described  in  the  following  excerpt 
from  the  text  file: 
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SGML  COMMENT 

<! —  This  document  was  created  from  pages  provided  by  the 
U.S.  Navy,  scanned,  marked  up  using  the  Avalanche  Intelli¬ 
gent  Markup  System,  cleaned  and  verified  using  SoftQuad 
Author/Editor  and  double  checked  with  the  Sobemap 
MARK-IT  parser.  — > 

The  fragment  used.  Chapter  3,  constituted  only  a  portion  of  what  would  have 
been  found  in  a  complete  transmission  of  an  SGML  tagged  text  file.  The 
original  document  was  scanned  by  a  third  party  and  was  not  available  to  the 
person  overseeing  the  tagging  and  composition.  A  printed  copy  of  the  origi¬ 
nal  source  document  was  not  given  to  the  CTN  test  platform  or  any  of  the  test 
participants.  The  second  document  was  a  special-purpose  CTN  “circuit  test” 
document.  The  intent  of  this  document  was  to  provide  measured  blocks  of 
text  (1000  and  2000  characters)  to  highlight  differences  in  font  set-widths  and 
vertical  leading  and  to  exaggerate  certain  conditions  encountered  in  hyphenat¬ 
ing  and  justifying  lines  of  text. 

Six  sets  of  paper  images  were  received  from  the  group  that  volunteered.  Each 
of  the  contributors  supplied  comments  regarding  their  SGML  parsing  actions 
and  any  fixes  that  they  made  to  the  source  files.  Only  five  image  sets  had 
been  received  by  the  time  the  preliminary  results  were  prepared  for  the  Winter 
TechDoc  meeting  in  New  Orleans.  One  set  (from  Software  Exoterica)  was 
not  included  because  it  did  not  follow  MIL-B  but  rather  followed  the  Cana¬ 
dian  National  Defense  Forces  guidelines  for  technical  documentation. 
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2  Test  Results 


The  test  methods  for  this  experiment  differed  completely  from  any  of  the  tests 
previously  conducted  by  a  CTN  test  platform.  All  observations  were  purely 
visual,  with  no  assists  from  the  usual  array  of  test  tools  that  have  been  ac¬ 
quired  or  developed  for  the  Technical  Publications  Text  Platform.  The  test 
procedure  was  purely  ad  hoc,  and  therefore,  readers  are  invited  to  add  their 
own  observations  to  the  analysis  of  the  results  presented  here.  Section  5 
contains  the  viewgraphs  presented  at  TechDoc  Winter  ’89.  They  are  num¬ 
bered  as  Exhibits  1  through  35. 

The  graphic  material  presented  here  and  in  the  TechDoc  presentation  was 
created  by  photostating  selected  pages  of  the  hard  copy  received,  and  then 
cutting  out  and  mounting  interesting  portions  of  each  photostat  for 
side-by-side  comparison. 

The  Exhibits  use  a  convention  of  displaying  four  examples  in  two  rows,  with 
the  upper  left  example  taken  from  Vendor  “A”  output,  upper  right  from 
Vendor  “B,”  lower  left  from  Vendor  “C,”  and  lower  right  from  Vendor  “D.” 
Vendor  “E”  output  was  not  used;  Vendor  “F”  output  arrived  too  late  to  be 
included  in  the  TechDoc  Exhibits,  but  is  discussed  in  this  report.  The  letter 
designations  rather  than  vendors  names  were  used  to  ease  the  discussion  of 
test  results,  rather  than  to  cloak  the  identity  of  the  participants.  Because  this 
experiment  aimed  at  obtaining  consensus  rather  than  measuring  conformance, 
the  identity  of  the  participants  is  only  of  casual  interest.  Table  1  is  provided 
for  those  whose  curiosity  is  still  unmitigated. 

Table  1  PSST  Participating  Vendors  Code  Letters 


A. 

SoftQuad 

D. 

B. 

Scribe 

E. 

C. 

Datalogics 

F. 

Interleaf 

Software  Exoterica 
Context 


The  test  results  for  both  documents  were  similar.  In  previous  reports,  each 
document  tested  was  discussed  separately  in  order  to  focus  on  the  results  from 
processing  digital  files.  In  this  experiment,  both  documents  will  be  discussed 
concurrently  with  differences  between  the  documents  noted  where  interesting. 
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The  general  progression  of  analysis  will  start  with  “headings”  (chapter  and 
section  heads,  running  heads)  and  continue  with  discussions  on  paragraph 
headings,  justification,  lists,  tables,  and  page  layout  efficiency, 

2.1  Headings 

The  first  page  of  the  documents  showed  a  startling  difference  in  overall 
appearance  or  gestalt.  (See  Exhibits  5  and  18  and  Figure  1  in  the  Executive 
Summary.)  In  addition  to  the  obvious  variations  in  type  faces  and  sizes,  the 
omission  or  inclusion  of  certain  elements  of  text  was  not  uniform.  Substantial 
variations  such  as  those  seen  here  were  not  expected  in  that  MIL-B  provides 
specific  guidelines  with  respect  to  style  of  face,  type  size,  and  manner  of 
emphasis.  See  Exhibits  31-33.  It  is  clear  from  the  lack  of  consensus  that: 

a.  MIL-B  is  too  ambiguous  or  difficult  to  interpret,  or  that 

b.  the  DTD  in  MIL-M-28001  requires  clarification,  or 

c.  the  Vendors  felt  that  the  dicta  of  MIL-B  did  not  apply  to  these  docu 
ments. 

This  writer  finds  it  difficult  to  defend  the  clarity  of  MIL-B.  (See  discussion 
under  “Paragraph  Headings.”)  However,  most  paragraphs  and  sentences  that 
will  affect  the  image  appearance  can  be  interpreted  in  some  positive  manner, 
and  not  ignored.  It  would  seem  that  if  the  OS  to  be  added  to  MIL-M-28001 
were  at  the  same  level  of  rigorous  specification  as  is  the  DTD  in  Appendix  A 
of  Specification  MIL-M-28001,  then  the  variability  in  format  style  would  be 
at  least  sharply  reduced. 

Exhibit  6  shows  the  differences  of  interpretation  regarding  technical  document 
numbering,  running  heads  and  security  classification  markings.  Only  Vendor 
B  provided  a  mnning  head,  but  no  technical  manual  number.  Only  Vendor  C 
provided  a  place  holder  for  the  technical  manual  number.  The  front  matter 
tags  which  would  supply  a  value  for  technical  manual  number  were  not 
present  in  this  fragment.  As  observed  by  this  writer, 

a.  documents  that  are  entirely  unclassified  do  not  have  any  security 
classification  marking; 

b.  running  heads  do  not  appear  on  pages  with  chapter  or  section  titles; 
and 
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c.  technical  manual  identification  numbers  appear  on  all  pages. 

The  documents  were  inconsistent  in  this  respect. 

The  five  sources  included  in  this  analysis  (Vendor  E  was  excluded)  produced 
images  for  8.5  by  11 -inch,  two  column  format,  conforming  to  MIL-B  guide¬ 
lines.  All  five  inputs  presented  “Chapter  3”  as  centered,  bold,  in  a  type  size 
larger  than  the  body  of  text.  The  title,  “Functional  Description”,  appeared  in 
the  same  style  directly  underneath  the  chapter  number.  Four  of  the  five 
samples  used  a  sans-serif  typeface  for  the  titles.  Vendor  B  used  a  serif  type¬ 
face.  The  typeface  was  consistent  with  the  chapter  title. 

2.2  Section  Heads 

The  omission  or  inclusion  of  certain  elements  is  a  more  serious  matter  than 
variations  in  type  size  and  placement.  Only  Vendors  B  and  C  included  the 
“Section  n”  head,  specified  by  the  <section  label="0">  tag  in  the  first  source 
file.  (See  Exhibit  4  for  the  SGML  input  and  Exhibit  7  for  the  formatted 
output.)  Vendor  A  ignored  the  tag  for  typesetting  purposes.  This  same  source 
used  a  horizontal  rule  to  separate  the  chapter  head  from  the  remainder  of  the 
text.  This  practice  is  not  suggested  by  MIL-B. 

The  attribute  value  of  label="0"  (Arabic  zero)  in  the  first  source  text  file  raises 
several  questions.  MIL-B  requires  that  sections  be  numbered  with  Roman 
numerals.  It  would  appear  that  the  value  for  the  attribute  is  impossible  to 
honor  in  the  context  of  MIL-B.  Vendors  B  and  F  converted  the  “0”  to  “I”, 
probably  by  manual  intervention.  Vendor  C  used  the  value  literally  just  as  the 
label  attribute  in  the  chapter  tag  was  used  literally.  The  second  source  file  did 
not  supply  a  value  for  the  label  attribute,  yet  Vendors  B  and  C  assumed  a 
default  value  of  “I”  and  printed  it  (see  Exhibits  7  and  21).  The  questions 
raised  here  then  are: 

a.  should  an  SGML  parser  be  fed  the  permissible  values  for  attributes 
and  check  them,  and 

b.  should  the  OS  specify  the  default  values  to  be  assumed  when  an 
attribute  is  missing? 
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In  the  second  document,  the  differences  were  even  broader.  Vendor  A  did  not 
use  a  page  break  and  start  a  new  page  as  recommended  by  MIL-B.  This, 
coupled  with  the  absence  of  a  section  head  and  any  paragraph  numbering, 
made  the  beginning  of  section  two  hard  to  find.  Vendor  B  did  supply  the 
section  heading,  but  without  a  page  break.  Vendor  C,  D,  and  F  all  started  a 
new  page  for  the  second  section. 

2.3  Paragraph  Headings  And  Numbering 

Exhibits  9  and  23  provide  examples  of  paragraph  headings  and  numbering. 
The  table  below,  based  on  the  first  test  document  (Exhibit  9),  presents  the 
most  noticeable  differences.  Some  corrections  to  the  Exhibits  are  included  in 
the  table.  The  row  headings  of  the  table  are  abbreviated  questions,  and  the 
cell  entries  are  answers  by  vendor.  Vendor  F  is  included  in  Table  2,  but  not  in 
the  Exhibits.  If  any  row  contained  all  “yes”  or  “no”  entries,  then  the  vendors 
would  be  in  consensus  about  that  question. 


Table  2.  Paragraph  Header  Styles 


Vendor 

A 

B 

C 

D 

F 

Consensus 

MIL-B  numbering 

yes 

yes 

yes 

yes 

yes 

5/5 

Same  face  as  body 

yes 

yes 

yes 

no 

yes 

4/5 

1st  Heads  underlined 

no 

yes 

yes 

yes 

yes 

4/5 

2nd  Heads  underlined 

yes 

yes 

yes 

yes 

yes 

5/5 

Heads  boldface 

no 

yes 

no 

yes 

no 

3/5 

Same  size  as  body 

yes 

n/y 

yes 

yes 

yes 

4/5 

Heads  italicized 

no 

yes 

no 

no 

no 

4/5 

The  major  item  of  disagreement,  in  this  case,  seems  to  be  the  use  of  boldface 
type  in  the  paragraph  headings.  Even  though  the  numbers  indicate  a  high 
degree  of  consensus,  the  appearance  of  the  headings  in  Exhibits  9  and  23 
provides  a  different  impression.  It  is  interesting  to  note  that  Figure  3  from 
MIL-B  (Exhibits  32  and  33)  does  not  mention  underlining  as  a  means  of 
emphasizing  paragraph  and  subparagraph  heads. 
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In  the  second  test  document,  a  surprise  was  encountered.  This  document  was 
tagged  as  having  two  sections.  Vendor  A  did  not  number  the  paragraphs  at 
all.  Vendors  B  and  F  began  the  second  section  with  a  primary  paragraph 
numbered  “7.”  Vendor  D  began  the  second  section  with  “1-7.”  Vendor  C 
began  the  second  section  with  “2-1,”  the  method  of  paragraph  numbering  that 
this  author  thought  was  prescribed  by  MIL-B. 

After  some  research,  an  explicit  definition  of  how  to  number  paragraphs  could 
not  be  found  in  MIL-B,  paragraphs  “3.2.3  Numbering,”  or  “3.2.1 1  Divisions,” 
or  in  the  illustrations  provided  in  Exhibit  34,  and  MIL-B  Figures  6  (Exhibit 
35),  9. 17, 22, 23,  and  42. 

MIL-B  is  incomplete  with  respect  to  defining  how  primary  paragraphs  will  be 
numbered  when  the  various  combinations  of  chapters  and  sections  occur.  The 
first  test  document  used  the  combination 

<body><chapter>...<section><paraO>  whereas  the  second  document  used 
only  <body><section><paraO>.  The  OS  now  under  review  should  give 
attention  to  this  particular  matter. 

The  requirement  to  use  run-in  text  for  subordinate  sideheads  (“The  text  shall 
begin  on  the  same  line  as  the  title,...”  —  MIL-B,  page  12,  last  paragraph)  was 
followed  by  four  of  the  five  outputs  examined. 

After  the  presentation  at  TechDoc,  another  anomaly  with  paragraph  heads  was 
discovered.  In  this  case.  Vendors  A  and  D  apparently  did  not  recognize 
<subpara2>  tags.  For  example,  in  preparing  the  text  file.  Vendor  A  chose  to 
use  the  follow  sequence  of  tags  (lines  without  tags  have  been  deleted): 

Document  1:  List  Tagged  as  Procedural  Steps 

<SUBPARA1  LABEL="3-3.12"  HCP="0" 

SCILEVEL="0"><TITLE  >5-90  MHz  Multiplier  Module 
(AlO).  <fnTLE> 

<PARATEXT  >  Assembly  AlO  receives  5  MHz,  1  volt  (&PM; 
major  circuits  comprise  AlO:  </PARATEXT> 

<STEP1  LABEL="a."><PARATEXT  >5  MHz  Phase  Modulator 
<;/PARATEXT></STEPl> 

<STEP1  LABEL=’'b."><PARATEXT  >5  to  10  MHz  Doubler 
</PARATEXT></STEPl> 

<STEP1  LABEL="c."><PARATEXT  >10  to  30  MHz  Tripler 
</PARATEXT></STEPl> 

<STEP1  LABEL="d."><PARATEXT  >30  MHz  Band  pass  Filter 
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<;/PARATEXT></STEPl> 

<STEP1  LABEL="e."><PARATEXT  >30  to  90  MHz  Triplet 
</PARATEXT></STEPl> 

<STEP1  LABEL="f."><PARATEXT  >90  MHz  Driver/90  MHz 
<;/PARATEXT></STEPl> 

<SUBPARA2><TrrLE></TITLE>  <PARATEXT>One  90  MHz, 

AlO  Multiplier  is  about  +4  to  +6  Vdc  </PARATEXT> 

<ySUBPARA2> 

<SUBPARA2><TITLE></TITLE><PARATEXT></PARATEXT>  </ 
</SUBPARA2></SUBPARA  1  > 

The  automated  software  tagged  the  list  as  procedural  steps.  The  DTD  requires 
that  the  </stepl>  tag  be  followed  by  two  <subpara2>  sequences.  The  <sub- 
para>  tags  require  <title>  and  <paratext>  content.  In  any  event,  ignoring  a 
document  structure  tag  such  as  <subpara2>  is  difficult  to  explain  here  just  as  it 
was  with  the  <section>  tag.  A  simpler  method  of  tagging  would  have  been: 


Retagging  of  Fragment  Above 


<SUBPARA1  LABEL="3-3.12"  HCP="0" 
SCILEVEL="0"><TITLE  >5-90  MHz  Multiplier 
(AlO).  </riTLE> 

<PARATEXT  >  Assembly  AlO  receives  5  MHz,  1  volt  (&PM; 
major  circuits  comprise  AlO:  </PARATEXT> 

<randlist> 

<item>5  MHz  Phase  Modulator</item> 

<item>5  to  10  MHz  Doubler</item> 

<item>10  to  30  MHz  Tripler</item> 

<item>30  MHz  Band  pass  Filter</item> 

<item>30  to  90  MHz  Tripler</item> 

<item>90  MHz  Driver/90  MHz  Output  Amplifier</item> 
</randlist> 

<PARATEXT>One  90  MHz 

AlO  Multiplier  is  about  +4  to  +6  Vdc.  </PARATEXT> 
</SUBPARAl> 


This  method  avoids  the  use  of  <subpara>  tags  where  the  tagger  clearly  did  not 
want  the  sidehead  to  appear  in  the  composed  text.  The  use  of  the  <randlist> 
tag  without  the  label  attribute  reflects  this  writer’s  interpretation  of  the  list  in 
question  as  being  a  non-sequential  list  of  items. 


Continuing  on  the  subject  of  <subpara>  tags,  the  recognition/non-recognition 
phenomena  also  occurs  in  paragraph  3-3.27  of  the  first  document.  Vendor  A 
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and  Vendor  D  did  not  output  a  sidehead  that  corresponded  to  the  <subpara2> 
tag.  Vendors  C  and  F  output  a  sidehead  even  though  the  tag  had  no  value  for 
the  label  attribute.  It  is  assumed  that  these  vendors  have  composition  systems 
that  can  switch  from  explicit  values  to  computed  values  of  an  attribute.  The 
tagger  of  this  document  could  more  easily  have  used  successive  <paratext> 
tags  to  achieve  the  apparent  intent. 

The  subparagraph  numbers  at  the  end  of  the  first  document  appear  inconsis¬ 
tent,  but,  in  most  cases,  they  reflect  the  value  of  the  “label=”  attribute  in  the 
<subpara>  tags.  Those  tags  are  listed  below  (the  lines  have  been  truncated): 

<SUBPARA1  LABEL="3-3.27."><TITLE  >Filtered  Battery  Crossover 
<SUBPARA1  LABEL="3-3.28."><TITLE  >Time  Code  Buffer  (A33). 
<SUBPARA2  LABEL="3-3.29.r’><TITLE  >PPM  Amplifier  (A34). 
<SUBPARA2  LABEL="3-3.30."  HCP=”0"  SCILEVEL="0"> 

Vendors  B  and  F  did  not  handle  the  out-of-sequence  numbers  consistent  with 
the  label  attribute  values. 

2.4  Justification  And  Hyphenation 

MIL-B  states  the  following  “Copy  shall  be  prepared  as  specified  below,  unless 
it  can  be  prepared  as  economically  in  double-columned  justified  right  margin 
format.”  No  conclusion  can  therefore  be  drawn  by  examining  Exhibits  1 1  and 
25.  Vendors  C,  D,  and  F  clearly  thought  that  fully  justified  text  was  as  eco¬ 
nomical  to  produce  as  “ragged  right.”  The  truth  of  this  would  be  difficult  to 
determine  in  any  case.  Document  2  as  typeset  by  Vendor  F  contains  at  least 
one  example,  paragraph  8-3,  of  why  the  choice  of  fully  justified  text  must  be 
balanced  against  the  hyphenation  technique  to  be  used. 

On  the  subject  of  hyphenation,  and  for  the  purposes  of  this  report,  two  terms 
are  defined: 

•  hard  hyphen  -  a  hyphen  placed  in  the  source  text  file  by 
the  author,  as  in  “DC-to-DC  Converter;” 

•  soft  hyphen  -  a  hyphen  placed  in  the  image  of  the  text  at 

the  end  of  a  line  to  indicate  that  the  text  composition  software 
divided  a  word. 

An  SGML-tagged  text  file  cannot,  by  definition,  contain  soft  hyphens.  A  file 
of  tagged  text  is  a  source  file,  i.e.,  a  file  in  the  IWSDB  that  can  be  called  up 
for  composition  against  a  variety  of  OS’s. 
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With  respect  to  soft  hyphenation,  all  except  Vendor  B  employed  it.  Vendor  B 
did  not  appear  to  use  hyphenation  in  the  composition  of  either  document. 

Both  documents  were  composed  by  Vendor  B  with  left-justified  text. 

With  respect  to  typesetting  hard  hyphens,  this  test  provided  an  interesting 
case.  The  source  file  for  the  first  document  contained  several  cases  (see  table 
below)  where  a  hard  hyphen  was  followed  by  a  space.  In  the  Declaration 
portion  of  the  DTD  in  MIL-M-28001,  the  hyphen  character  is  not  declared  as 
a  token  separator  whereas  the  space  character  is  so  defined. 

Table  3.  Instances  of  a  Hyphen  Followed  by  a  Space 
(prefixed  with  line  number  of  source  document  1.) 


133  transformer-coupled,  DC-to-  DC  Converter  which 
250  out-of-  lock  signal  is  applied  to  the  A 19  Logic  Assembly 
268  signal.  A  1/4  wave-  length  cavity  selects  the 
464  output  and  by  R9  for  the  rear-  panel  100  KHz  output.  Q3 
503  to  the  time-of-day  display.  This  1-  second  step  is  needed 
612  <PARATEXT  >  A30  is  a  +28  Vdc  Float-Voltage  Charger, 
current-  limited 

658  code  output  level  is  +6  Vdc  PM;1  volt  for  time-  marks 


Examining  the  composed  text  from  Vendors  A,  D,  and  F  showed  that  they  all 
treated  the  ASCII  space  code  after  the  hyphen  as  a  token  or  word  separator 
and  placed  a  “space-between-words”  in  its  place. 

The  presence  of  the  gratuitous  space  code  has  another  impact.  If  the  source 
text  file  were  to  be  placed  in  an  IWSDB,  the  presence  of  this  space  code 
would  adversely  impact  the  indexing  of  the  text  as  well  as  the  use  of  text 
search  tools.  To  prevent  the  acceptance  of  data  with  this  flaw,  some  sort  of 
software  tool  will  have  to  be  added  to  quality  control  tools  (such  as  spelling 
checkers  and  SGML  parsers  needed  for  preparing  compliant  file  sets). 

2.5  Lists 
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The  fragments  of  the  list  in  the  first  document  are  shown  in  Exhibit  13.  The 
fragments  are  referred  to  here  as  lists  because  the  context  of  the  document 
permits  no  other  interpretation.  The  items  were  not  tagged  as  <randlist> 
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elements,  but  as  procedural  steps.  The  tagging  is  incorrect  in  this  context. 
Vendor  B  apparendy  decided  to  modify  the  input  so  that  their  composition 
software  would  typeset  this  as  a  list  (with  numbered  items  per  MIL-B,  see 
Exhibit  35)  rather  than  as  a  series  of  procedural  steps  (with  lower  case  letters 
for  each  item). 

The  list  revealed  an  interesting  case.  The  SGML  text  file  defined  an  entity 
that  was  intended  to  be  typeset  as  an  over-and-under  plus/minus  sign.  Refer¬ 
ring  to  Exhibit  13,  it  can  be  seen  that  only  two  of  the  examples  show  an  over/ 
under  plus/minus  character.  Vendors  A  and  B  typeset  this  character,  Vendor 
C  omitted  the  character,  and  Vendor  D  “rejected”  the  entity  reference,  as  did 
Vendor  F  (not  shown).  The  first  question  that  arises  is  whether  or  not  this 
entity  definition  is  the  proper  way  to  convey  this  type  of  data.  Various  alpha¬ 
bets  have  been  defined  in  IS  8879  to  cope  with  this  sort  of  situation.  One  of 
them  could  have  been  used.  A  second  question  arises  with  respect  to  one  of 
the  goals  of  MIL-STD-1840:  to  provide  the  maximum  degree  of  automated 
processing  possible.  The  use  of  this  sort  of  entity  requires  that  the  Destination 
System  have  someone  intervene  in  the  process  to  resolve  the  entity  reference. 
According  to  received  advice,  the  correct  manner  of  handling  the  entity  is 
shown  in  the  output  of  Vendor  D  in  Exhibit  13  where  the  entity  reference  was 
output  character  for  character. 

A  sharp-eyed  member  of  the  TechDoc  audience  noted  that  the  output  from 
Vendor  D  (Exhibit  13)  had  apparently  lost  some  text  that  follows  item  “c”  in 
the  list. 

Exhibit  27  from  the  second  test  document  shows  another  story.  The  list  was 
defined  as  <seqlist>.  The  most  noticeable  difference  is  that  Vendor  A  did  not 
number  the  list  items,  as  did  all  the  other  Vendors.  A  second  difference  is  in 
the  treatment  of  the  list  title,  “Word  List.”  This  title  was: 

a.  left  justified  by  Vendors  A  and  D; 

b.  typeset  as  a  subparagraph  title  by  Vendor  B; 

c.  centered  by  Vendor  C; 

d.  aligned  with  the  first  letter  of  the  words  in  the  list  by  Vendor  F. 

There  seems  to  be  little  consensus  on  this  relatively  simple  matter. 
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2.6  Tables 

Exhibits  15  and  29  show  fragments  from  the  tables  in  the  test  documents. 
Exhibit  29,  for  the  second  document,  has  a  placement  error.  The  examples  for 
Vendors  C  and  D  have  been  switched. 

The  exhibits  cannot  show  the  placement  of  the  table  relative  to  the  text  that 
refers  to  it.  For  the  first  document,  the  placement  was  consistently  correct: 
that  is,  the  table  appeared  reasonably  soon  after  the  text  reference  to  it.  The 
placement  of  the  two  table  occurrences  for  the  second  document  is  relatively 
consistent,  except  for  Vendor  B,  who  placed  both  tables  before  the  text  that 
referred  to  it. 

Exhibit  15,  for  the  first  document,  shows  an  inconsistency  in  placement  of  the 
table  title  by  Vendor  B.  In  this  exhibit,  the  placement  of  the  examples  varies 
slightly  because  of  the  size  of  the  fragments.  The  upper-most  fragment  is 
from  Vendor  A,  the  next  from  Vendor  B,  and  so  on.  Vendor  F  set  the  table 
within  one  column  in  double  column  text.  This  was  not  in  accordance  with 
the  table  tag  attributes.  Exhibit  29  shows  that  Vendor  A  did  not  assign  a 
number  to  the  table. 

The  use  of  rules  within  the  table  in  the  first  document  was  obviously  inconsis¬ 
tent.  The  table  tags  called  for: 


siderules  explicitly 

Conformance: 

4/5 

rules  between  columns  explicitly 

Conformance: 

4/5 

no  rules  between  rows  by  default 

Conformance: 

3/5 

portrait  orientation  by  default 

Conformance: 

5/5 

full  page  width  by  default 

Conformance: 

4/5 

A  reading  of  MIL-M-28001  did  not  reveal  any  particular  ambiguity  or  incon¬ 
sistency  in  the  definition  of  the  attributes  for  the  <tabdef>  tag.  Head  and  foot 
rules  were  consistent,  but  horizontal  rules  within  the  table  were  not.  Vendor  F 
set  the  table  with  no  horizontal  rules  other  than  head  and  foot.  That  vendor 
also  set  the  table  with  no  vertical  mles  (acceptable  per  MIL-B),  but,  again,  not 
in  accordance  with  the  table  tag  attributes. 
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In  the  second  document,  (Exhibit  29)  the  use  of  rules  was  more  consistent. 
The  <tabdef>  tags  in  this  document  specified: 


siderules  explicitly 

Conformance: 

5/5 

rules  between  columns  explicitly 

Conformance: 

5/5 

rules  between  rows  explicitly 

Conformance: 

5/5 

portrait  orientation  by  default 

Conformance: 

5/5 

full  page  width  by  default 

Conformance: 

5/5 

Apparently,  the  explicit  requirement  for  rules  between  rows  caused  all  the 
vendors  to  comply,  whereas  in  the  first  document  the  default  requirement  was 
ignored  by  Vendors  B  and  D. 

In  several  cases,  the  composition  of  the  second  document  caused  a  table  to  be 
split  across  two  pages.  In  this  case  MIL-B  (3.2.9.2.3  and  Figure  8)  states  that 
the  “closing”  rule  is  omitted  at  the  foot  of  a  continued  table  or  chart;  the 
“opening”  rule  is  omitted  at  the  head  of  the  continuation  thereof.  In  the  two 
cases  where  the  table  was  continued,  the  closing  and  opening  rules  were  not 
omitted.  In  this  case  there  is  a  conflict  between  MIL-B  typesetting  rules  and 
the  specifics  required  by  the  attributes  in  the  <tabdef>  tags.  The  OS  must  take 
account  of  situations  like  this,  and  provide  a  hierarchy  of  rules. 

The  <colbddef>  tags  for  this  table  specified  left  justification  for  column  2, 
centering  for  column  3,  right  justification  for  column  4,  and  default  values  for 
columns  1  an  5.  The  <colbddef>  attribute  “right=l”  (right  justify  all  entries) 
for  column  four  of  this  table  was  heeded  by  all  but  Vendor  F.  All  Vendors 
honored  the  default  and  explicit  alignment  direction  for  the  other  columns. 

Column  10,  row  5  of  the  second  document  contains,  by  design,  more  text  than 
can  fit  on  a  single  line.  None  of  the  vendors  had  any  difficulty  in  setting  a 
“mini-paragraph”  in  this  cell.  Vendor  F  also  extended  column  10  row  3  to  a 
second  line  containing  one  word. 

The  width  attribute  values  in  the  <entry>  tag  are  supposed  to  sum  to  100%, 
but  did  not.  Vendor  C  noted  in  the  listing  of  the  second  document  after 
correcting  tagging  errors  that  several  of  the  values  for  “width=”  were  changed. 
This  may  have  produced  a  more  acceptable  appearing  output,  but  was  contrary 
to  the  spirit  of  the  experiment.  It  is  not  known  if  any  of  the  other  sources  also 
changed  these  width  values. 
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2.7  Page  Layout 

Given  that  the  body  of  the  text  is  typeset  to  provide  easily  readable  material 
(considering  type  size,  line  length,  justification  and  vertical  leading),  there  is 
some  interest  in  the  relative  efficiency  of  presenting  the  text;  i.e.,  the  amount 
of  text  per  page.  If  readability  criteria  can  be  met,  then  the  more  text  per 
page,  the  better.  Another  way  of  saying  this  is  that  the  more  compact  the 
document,  the  lower  the  cost  to  produce,  maintain,  store,  and  use.  The  list 
that  follows  recounts  the  number  of  pages  needed  to  print  the  first  document. 

•  Vendor  A  -  8  pages,  last  page  1/3  full 

•  Vendor  B  -  6  pages,  last  page  nearly  full 

•  Vendor  C  -  6  pages,  last  page  full 

•  Vendor  D  -  6  pages,  last  page  1/3  full 

•  Vendor  F  - 12  pages,  last  page  half  full 

Vendor  F  output  seemed  to  be  double  spaced  in  double  columns.  In  the 
second  document,  the  vertical  leading  was  closer  to  the  expected,  although 
still  very  liberal.  Comparisons  of  efficiency  for  the  second  document  are 
difficult  because  of  the  varying  interpretation  of  the  second  occurrence  of  a 
<section>  tag  previously  mentioned. 

The  status  attribute  in  the  <doc>  tag  for  the  second  document  had  a  value  of 
“draft.”  The  default  value  for  the  status  attribute  is  “formal.”  Vendor  C 
interpreted  the  value  “draft”  to  mean  that  the  text  should  be  set  in  classic  draft 
form  (double  spaced),  while  the  other  sources  ignored  this  attribute  value. 

The  question  that  arises  here  is  how  to  interpret  attributes.  That  is,  when  is 
the  value  of  an  attribute  for  information  only  and  when  should  it  be  heeded 
and  acted  upon.  This  issue  occurred  many  times  during  the  analysis  of  the  test 
data. 

Vendor  B  did  not  adhere  to  the  recommended  20  pica  width  for  double¬ 
column  format.  (See  Exhibit  16.) 
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3  Summary  of  Recommendations 

The  recommendations  stemming  from  this  experiment  apply  to  four  topics: 
the  DTD  in  MIL-M-28001,  the  OS  in  MIL-M-28001,  MIL-B,  and  future  tests. 

3.1  DTD  Of  MIL-M-28001 

It  is  clear  that  the  use  of  default  values  of  attributes,  for  document  mainte¬ 
nance  and  databasing  as  well  as  imaging,  requires  better  definition  than  is  now 
found  in  the  DTD  (MIL-M-28001).  Where  there  is  no  intent  in  the  DTD  that 
the  attribute  value  be  machine  processable  (i.e.,  interpreted  by  imaging  soft¬ 
ware),  then  that  condition  should  be  clearly  noted  as  a  deviation  from  the  rule. 
In  the  case  of  the  label  attribute  found  in  several  structure  tags,  the  number 
system  may  have  to  be  specified  along  with  the  range.  For  documents  to  be 
formatted  in  accordance  with  MIL-B,  for  example,  the  value  of  the  label 
attribute  in  the  section  tag  must  be  represented  by  Roman  numerals  ranging 
from  “I”  to  infinity.  Application  of  this  concept  would  permit  SGML  instance 
parsers  to  validate  the  attribute  values.  The  concept  is  also  format  dependent 
to  a  degree,  and  should  be  implemented  with  a  view  to  maintaining  the  format 
independence  that  is  the  intent  of  SGML.  An  alternative  approach  would  be 
to  define  the  values  found  in  attributes  such  as  “label”  as  Arabic  ordinal 
numbers,  where  the  imaging  software  is  required  to  map  the  attribute  value 
into  the  correct  numbering  system.  Although  either  approach  will  work,  the 
second  concept  seems  more  in  harmony  with  the  intent  of  SGML. 

Additionally,  it  is  suggested  that  a  policy  be  established  that  attributes  in¬ 
tended  to  convey  format-dependent  information  (such  as  paragraph  numbers) 
be  used  only  in  cases  (such  as  change  pages)  where  the  value  cannot  be 
computed  from  the  initial  conditions  assumed  for  “page  1.” 

The  “plus-minus”  entity  defined  in  the  first  document  raises  an  issue  with 
respect  to  automation.  It  is  questionable  whether  defining  a  typographic 
object  outside  of  the  alphabets  already  defined  in  IS  8879,  where  one  of  those 
alphabets  provides  the  object  wanted,  ought  to  be  accepted  practice.  In 
general,  it  seems  undesirable  to  require  human  intervention  to  match  an  entity 
description  to  an  available  typesetter  character  when  composing  an  image.  In 
a  highly  automated  environment  it  would  be  desirable  to  make  the  match  one 
time  for  a  large  group  of  documents  and  record  the  match  “in”  the  composi¬ 
tion  software. 
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There  were  several  cases  of  incorrect  use  of  the  DTD  of  MIL-M-28001  that 
passed  through  SGML  document  instance  parsers.  If  such  mis-applied  tag¬ 
ging  were  to  be  allowed  into  the  IWSDB  then  several  functions  that  the 
IWSDB  is  expected  to  support  will  be  impacted:  document  maintenance  and 
search  and  retrieval  of  document  content  being  two  examples.  Acceptance 
procedures  must  be  devised  that  can  detect  conditions  of  this  kind.  SGML 
parsers  cannot,  as  this  test  demonstrated,  detect  mis-application  of  a  DTD. 

Use  of  an  expert  system  might  be  one  approach  that  could  be  readily  imple¬ 
mented. 

3.2  OS  Of  MIL-M-28001 

The  results  of  the  composition  process  likewise  need  acceptance  methods, 
again  perhaps  by  an  expert  system  approach.  In  the  future,  contractors  may 
deliver  documents  in  PDL  form  when  those  documents  are  in  draft  status  or 
the  contractor  is  maintaining  the  document  and  the  customer  does  not  yet 
require  source  files  for  the  IWSDB. 

Some  SGML  tags  were  ignored  by  some  vendors  when  typesetting  the  test 
documents.  Acceptance  of  composed  pages,  in  either  printed  form  or  Page 
Description  Language  form,  must  verify  the  consistency  of  the  image  with  the 
SGML  tagging.  Omitting  a  major  structural  item  such  as  a  section  head  (from 
the  page  on  which  the  section  starts  and  from  the  table  of  contents)  will  be 
very  confusing  if  not  misleading  to  the  intended  readers. 

It  is  highly  probable  that  any  source  of  format  specification,  be  it  an  OS  or 
another  revision  of  MIL-M-38784,  will  have  to  attain  a  degree  of  rigor  equal 
to  the  DTD  that  it  supports. 

3.3  Specification  MIL-M-38784B 

It  may  be  that  the  OS  under  review  can  entirely  replace  MIL-B  with  respect  to 
format  specification.  This  would  be  the  most  straightforward  method  of 
untangling  some  of  the  difficulties  inherited  from  the  MIL-M-38784  series  of 
specifications.  Other  content  in  MIL-B  not  specifically  related  to  imaging 
issues  could  benefit  from  an  update  based  on  current  electronic  authoring  and 
production  practices. 
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3.4  Further  Tests 

The  use  of  document  fragments  in  this  test  left  some  questions  unanswerable 
because  the  tagged  text  that  would  have  provided  answers  was  missing. 
Except  in  the  case  of  tests  oriented  towards  transfers  of  sets  of  change  pages, 
it  is  recommended  that  only  complete  reference  documents  be  used  in  the 
future.  In  the  past,  it  has  been  CTN  policy  to  base  tests  only  on  documents 
that  have  been  approved  for  use.  This  policy  tends  to  filter  out  document 
instances  that  have  questionable  content  or  appearance.  It  is  recommended 
that  this  policy  be  continued. 

Future  PSST  tests  might  best  serve  CALS  goals  by  emphasizing  early  testing 
of  changes  and  additions  to  the  CALS  core  standards.  The  impending  OS  for 
Specification  MIL-M-28001  is  one  obvious  opportunity.  Considering  the  low 
degree  of  consensus  obtained  in  this  test,  another  test  with  the  same  group  of 
vendors  (others  could  be  added)  using  the  draft  OS  could  accelerate  the 
validation  process. 
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4  Exhibits 

Some  of  the  titles  of  Exhibits  (viewgraphs)  listed  below  have  a  parenthetical 
cross-reference  to  other  Exhibits  to  facilitate  comparisons  between  the  two 
documents.  The  titles  do  not  appear  on  Exhibits  32-35.  The  titles  given  are 
transcribed  exactly  from  MIL-B  (including  the  misspelled  word). 

1.  Publishing  Systems  Structured  Test;  An  Experiment  (PSST) 

2.  PSST  Objective 

3.  PSST  Contributors 


4. 

PSST  Input  1: 

Prepared  by  SoftQuad  (18) 

5. 

PSST  Output  1: 

A  Long  View  (19) 

6. 

PSST  Output  1: 

Chapter  Heading 

7. 

PSST  Output  1: 

The  Section  Head  (21) 

8. 

PSST  Output  1: 

Type  Faces  (22) 

9. 

PSST  Output  1; 

Paragraph  Heads  (23) 

10. 

PSST  Output  1: 

Paragraph  Heads  (Cont’d)  (24) 

11. 

PSST  Output  1: 

Justification  (25) 

12. 

PSST  Output  1: 

Layout  Efficiency  (26) 

13. 

PSST  Output  1: 

The  List  (27) 

14. 

PSST  Output  1; 

Running  Heads  (28) 

15. 

PSST  Output  1: 

The  Table  (29) 

16. 

PSST  Output  1: 

Column  Width 

17. 

PSST  Output  1: 

Summary  (30) 
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18.  PSST  Input  2:  Prepared  by  SYSCON  (4) 

19.  PSST  Output  2:  A  Long  View  (5) 

20.  PSST  Output  2:  Observations 

21.  PSST  Output  2:  The  Section  Head  (7) 

22.  PSST  Output  2:  Type  Faces  (8) 

23.  PSST  Output  2:  Paragraph  Heads  (9) 

24.  PSST  Output  2;  Paragraph  Heads  (Cont’d)  (10) 

25.  PSST  Output  2:  Justification  (11) 

26.  PSST  Output  2:  Layout  Efficiency  (12) 

27.  PSST  Output  2:  The  List  (13) 

28.  PSST  Output  2:  Running  Heads  (14) 

29.  PSST  Output  2:  TheTable(15) 

30.  PSST  Output  2:  Summary  (17) 

31.  Specification  MIL-M-38784B:  excerpt  from  page  5. 

32.  Specification  MIL-M-38784B:  Figure  3.  Style,  size, 

capitalization,  leading  and 
spacing  (typeset). 

33.  Specification  MIL-M-38784B:  Figure  3.  Style,  size, 

capitalization,  leading  and 
spacing  (typeset)  -  continued. 

34.  Specification  MIL-M-38784B:  Figure  6.  Example  of  single¬ 

column  unjustified  copy. 

35.  Specification  MIL-M-38784B:  Figure  5.  Example  of 

double-columned  unjustified 
text. 
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PSST  CONTRIBUTORS 
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PSST  OUTPUT  2:  THE  TABLE 
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PSST  OUTPUT  2:  SUMMARY 
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negatives  as  specified  by  the  acquiring  activity  (multiframe  negatives  for  foldouts)  suitable  for 
subsequent  enlargement  to  full  size  photolithographic  negatives  which  will  be  used  to  produce 
offset  printing  plates.  Minimum  acceptable  material  shall  have  the  following  features: 
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lessening  usability  or  clarity  of  material.  (See  figures  3  and  6.)  Blank  pages  and  spaces  shall  be 
avoided,  v/henever  possible.  Leading  and  spacing  as  indicated  by  figure  3  shall  be  used  for  best 
legibility  and  conservation  of  space.  Double  spacing  of  text  within  a  paragraph,  or  similar 
wastefulness,  is  unacceptable.  Slight  variations  are  permitted  in  order  to  avoid  layout  practices 
that  would  result  in: 
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RADAR  SCT 
•  AN/SPS^IQI  ) 


$C2nRCVMMA^10/SFS-10 


SECT10R  4 
SCHEOULCOMAIMT«NANC€ 


4-3  PREVOrriVE  MAINTENANCE  PPOCSDURES 


Th«  preventive  maintenance  proce¬ 
dures  listed  below  provide  information 
necessary  to  conduct  a  comprehensive  pro< 
gram  of  cleaning  and  inspecting  the  AN/ 
SPS-10.  Each  procedure  includes  equip- 
■eat  and  aaterials  required  and  step-by- 
seep  instructions  on  how  to  perform  the 
preventive  uintenance. 


Comply  with  Navy  Safety 
Precautions  for  Forces 
Afloat,  OPNAVINST  5100 
series  prior  to  performing 
preventive  maintenance. 

4-3.1  AIR  FILTER  CLEANING  PROCEDURES. 
The  air  filters  in  the  Receiver-Trans¬ 
mitter,  the  Modulator,  and  the  Video 
Clutter  Suppressor  (AN/SPS-10  Field 
Change  No.  22,  30,  or  31  incorporated) 
should  be  cleaned  monthly. 

4-3. 1.1  Tools  and  Equipment  Required. 


4.  For  equipments  with  Video 
Clutter  Suppressor  MX-0.756A/SPS-IO,  locate 
filter  inside  cabinet  door. 

4-3. 1.3  Procedures  for  Cleaning  Air 
Filters. 

1.  Remove  filters. 

2.  Vacuum  filters,  reversing  nor¬ 
mal  air  flow. 

3.  Inspect  filters  for  cleanli¬ 
ness.  If  additional  cleaning  is  required: 

a.  Wash  filters  in  solution  of 
warm  water  and  detergent 

b.  Rinse  filters  in  clean,  fresh 

water* 

c.  Blow  excess  moisture  from 
filters  with  lo%#-pressure  air. 

d.  Allow  filters  to  dry 
thoroughly. 

4.  Reinstall  cleaned  filter. 

5.  Return  equipment  to  normal 
readiness  condition. 

4-3.2  AS-936(  )/SPS-10B  ANTENNA  ASSEMBLY 

AND  OIL  LEVEL  INSPECTION,  AND  LUBRICATION 
OF  ANTENNA  DRIVE  MOTOR.  These  maintenance 
procedures  should  be  performed  quarterly, 
when  AS-936(  )/L.  ;-10B  Antenna  Assembly 
(Units  19,  20,  or  21)  is  installed. 


1.  Wanting  tags 

2.  Vacuum  cleaner  with  non-metaiic 
nozzle 


High  voltages  that  are 
dangerous  to  life  may 
be  stored  on  capacitors 
after  power  is  removed. 

4-3. 1.2  Preliminary  Actions. 

1.  Turn  OFF  and  tag  radar  buDchead 
main  power  switch  in  radar  equipment 
room. 

2.  Locate  filter  in  center  under¬ 
side  of  Receiver-TransBUtter  cabinet. 

3.  Locate  filter  on  right  side 
below  connector  panel  on  Modulator  ca¬ 
binet. 


4-3. 2.1  Tools  and  Equipment  Required. 

1.  Clean  rags 

2.  Warning  Tags 

3.  Small  funnel 

4.  Safety  harness 

5.  Oil,  MIL-L-9000  or  MIL-L-17331 

6.  Grease,  MIL-O-23827 

7.  Grease,  MIL-0-01322 

8.  8"  adjustable  wrench 

9.  3/4*  fill  pipe  with  grease  cap 

4-3. 2. 2  Preliminary  actions. 

1.  Comply  with  ship's  regulations 
for  vrorking  aloft. 

2.  Turn  off  and  tag  radar  buDthead 
main  power  switch. 

3.  Press  STOP  button  on  Manual 
Controller  Switch  and  tag  "MAN  ALOFT". 

4.  Turn  Antenna  Switch  Control 
to  OFF  RESET. 
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CHAPTER  3 

HANDLING  AND  STORAGE 


3-1.  GENERAL.  Compliance  with  APR  127-100  and  the  instructions  in  this  manual 
will  ensure  sale  handling,  storage,  and  serviceability  of  widgets.  Waivers  and 
deviations  will  be  in  accordance  with  APR  127-100.  Stored  widgets  should  be 
protected  from  adverse  climactic  conditions.  The  main  hazards  linked  with  the 
storage  and  handling  of  items  listed  in  this  TO  are: 

a.  Blast. 

b.  Pragments. 

c.  Pire. 

3-2.  SPECIAL  TERMS.  The  following  terms,  as  defined,  apply  to  widgets. 

NOTE 

Shell  and  service  lives  are  not  cumulative.  Any  combination  of  shelf  and  service 
life  accrued  by  an  item  cannot  exceed  the  shelf  life. 

3-2.1.  Shelf  life:  The  length  of  time  an  item  can  remain  in  storage.  The  expiration 
date  for  shelf  life  on  items  with  the  month  and  year  listed  is  the  last  day  of  the  month. 

^•2*2  Service  life:  The  length  of  time  an  item  can  remain  in  operating  configuration 
or  in  actual  usage. 

NOTE:  For  those  items  packed  in  hermetically  sealed  tear  strip 

containers  service  life  starts  on  date  of  opening  and  continues  until  item(s)  are 
expended. 

3-2.3  Magazine:  Any  building  or  structure,  except  an  operating  building,  used  for 
storage  of  explosives,  munitions,  or  loaded  munition  components. 

3-3.  IDENTIFICATION.  The  use  of  standard  nomenclature  and  lot  number /serial 
number  is  mandatory  for  all  storage  records  and  communications.  Legible 
identification  markings  will  be  kept  on  munitions  in  storage. 


FIGURE  6. Example  of  single-column  unjustified  copy. 


